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REMARKS 

Response to Notice of Non-Compliant Amendment 

The Examiner issued a Notice of Non-Compliant Amendment, which was 
mailed on July 10, 2008. In the Notice, the Examiner indicated that "Claimed 
amendment does not point out specific paragraphs in the specification of the claimed 
invention on the remark of the amendment filed in January 1 0, 2008", citing 37 CFR 
§1-111. 

Applicants' representative has reviewed 37 CFR §1.111, and does not agree 
that this rule requires that specific paragraphs be pointed out to the Examiner. 
Furthermore, Applicants submit that contrary to the Examiner's assertions, the 
allegedly Non-Compliant Amendment, which was filed January 10, 2008, provided 
appropriate support for the amended claim language (see, e.g., pages 1 1-12 of the 
Amendment, which provides a detailed description of Fig. 3, the detailed description, 
of which, was obtained directly from the specification). 

However, to expedite prosecution, Applicants' representative contacted the 
Examiner on August 1, 2008, to confirm that the representative's understanding of 
what the Examiner has required is correct. The Examiner confirmed that the 
representative's understanding was correct - that the Examiner believes that 
Applicants must provide support from the specification for the amended claim 
language to satisfy the Examiner's requirement. 

Accordingly, and to expedite prosecution, the remarks of the present 
Amendment have been updated so as to provide the Examiner with specific 
paragraphs of the specification that support the amended claim language. This 
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information has been added in bold type to distinguish from the previously 
submitted remarks. No other changes have been made to the Amendment. 

Furthermore, it should be noted that many of the amendments to claims 1 , 3-6 
and 8-16 were minor editorial amendments, and did not change the scope of the 
claims. Accordingly, Applicants submit that any amendments for which support has 
not been provided for herein are fully supported by the originally filed claims. 

Status of Claims 

The present Amendment amends claims 1, 3-6 and 8-16. Therefore, the 
present application has pending claims 1, 3-6 and 8-16. 

Claim Objections 

Claims 1,6, 11 and 15 stand objected to due to informalities noted by the 
Examiner. Where appropriate, Applicants amended claims 1,6, 11 and 15 to correct 
the informalities. Therefore, this objection is overcome and should be withdrawn. 

However, regarding claim 1, Applicants traverse this objection for the 
following reasons. On page 3 (paragraph 7) of the Office Action, the Examiner 
alleges that there is insufficient antecedent basis for "a token revoke request" as 
recited in claim 1 , line 6. However, Applicants submit that "a token revoke request 
means" is first recited in line 6, and "a token revoke request" is first recited in lines 6- 
7. Therefore, "a token revoke request means" provides sufficient antecedent basis 
for any further recitations of a token revoke request means, and "a token revoke 
request" provides sufficient antecedent basis for any further recitations of a token 
revoke request. Accordingly, the objection to claim 1 should be withdrawn. 
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35 U.S.C. §101 Rejections 

Claims 15 and 16 stand rejected under 35 U.S.C. §101 as allegedly being 
directed to non-statutory subject matter. Applicants have amended claims 15 and 16 
in accordance with the Examiner's recommendations. Accordingly, Applicants 
submit that claims 15 and 16, as more clearly recited, are directed to statutory 
subject matter and are in compliance with the provisions of 35 U.S.C. §101. 

Allowable Subject Matter 

The Examiner indicated that claims 4, 5, 9, 10, 13 and 14 would be allowable 
if rewritten to overcome the claim objections set forth in the Office Action, and to 
include all the limitations of the base claim and any intervening claims. 

Applicants submit that the claim objections set forth in the Office Action are 
overcome. Furthermore, minor editorial amendments were made to claims 4, 5, 9, 
10, 13 and 14 to make these claims consistent with the claims that were objected to. 
Accordingly, the subject matter of claims 4, 5, 9, 10, 13 and 14 remains allowable. 

35 U.S.C. §103 Rejections 

Claims 6, 8, 15 and 16 stand rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over U.S. Patent No. 5,634,122 to Loucks et al. ("Loucks") in view of 
U.S. Patent No. 5,175,851 to Johnson et al. ("Johnson"). This rejection is traversed 
for the following reasons. Applicants submit that the features of the present 
invention, as now more clearly recited in claims 6, 8, 15, and 16, are not taught or 
suggested by Loucks or Johnson, whether taken individually or in combination with 
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each other in the manner suggested by the Examiner. Therefore, Applicants 
respectfully request the Examiner to reconsider and withdraw this rejection. 

Amendments were made to the claims to more clearly describe features of the 
present invention. Specifically, amendments were made to the claims to more 
clearly recite that the present invention is directed to a file send and receive method 
and a program as recited, for example, in independent claims 6, 15 and 16. 

The present invention, as recited in claim 6, and as similarly recited in claims 
15 and 16, provides a file send and receive method used in a distributed file system. 
The distributed file system includes a storage device for holding files, multiple clients 
for carrying out file operations on the storage device, a server using tokens to control 
rights to file reading and writing operations by the clients, and a network connecting 
the clients, the storage device and the server. The method includes making a 
request to the server for a token for rights to perform the file operations, wherein a 
first client makes the request to the server, and sending, by the server, the token 
revoke request to a second client that holds write operation rights to the file, so as to 
request a return of the token for the write operation rights. According to the present 
invention, the token revoke request includes information identifying the first client 
that requested the token for the file, and information indicating a level of the token 
requested by the first client, the level being either read or write. The method also 
includes sending, by the second client that received the token revoke request, the 
file for the token held in the memory section, to the first client that requested the 
token for the file. The prior art does not teach or suggest all of these features. 

As shown in Fig. 3 of the present invention, the token request message is 
comprised of a file ID field 41 , a revoke token class field 42, a range specifier field 
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43, request token level field 44, and a token request node ID field 45. The file ID 
field 41 shows information on the file for the token request. The revoke token class 
field 42 shows the class of token (for example, data, attribute, size, file name, etc.). 
The range specifier field 43 shows the file range. In a distributed file system where a 
token can specify the file range, the client only needs to process the range specified 
in the range specifier field 43. The request token level field 44 shows the level 
(read/write) of the token. The token request node ID field 45 shows information on 
the request source client requesting the token. {See, e.g., page 15, lines 8-17 of 
the present specification). 

As such, the revoke request message contains information on the node (client 
11) requesting the token, and the level (read or write) of the requested token (level 
requested by the client 11). In the present invention, when the server issues a 
revoke-request to a node holding a token, information on the node requesting the 
token is also added to that revoke-request. Therefore, the file for that token does not 
have to be written back into the storage device and is delivered while still in a dirty 
state. Taking these steps allows reducing as much as possible the number of times 
the storage device is subjected to I/O processing (accessed) and processing is 
performed in parallel. 

The above described features of the present invention, as now more clearly 
recited in the claims, are not taught or suggested by any of the references of record. 
Specifically, the features are not taught or suggested by either Loucks or Johnson, 
whether taken individually or in combination with each other. 

Loucks teaches a system and method for multi-level token management for 
distributed file systems. However, there is no teaching or suggestion in Loucks of 
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the file send and receive method and program as recited in claims 6, 15 and 16 of 
the present invention. 

Loucks discloses a system and method for controlling access to shared 
resources in a distributed computer system. Access to shared resources is 
controlled by a local authorization token manager. Only computer processes holding 
authorization tokens for the requested operation may perform that operation. Each 
requested operation checks for the proper token. If the token is not held by the 
process, it is requested. The local token manager resolves token conflicts before 
granting tokens. A token manager of a distributed file system export protocol also is 
able to request authorization tokens from the local token manager. The export 
protocol token manager controls authorization tokens for that particular distributed 
file system protocol. Multiple different export protocols may request tokens from the 
local token manager. The shared resources may therefore be shared by multiple 
different export protocols without conflict. Local processes and processes 
requesting shared resource operations through an export protocol that does not itself 
manage tokens are granted tokens through the operation token request mechanism. 
This mechanism enables local processes to use shared resources without the 
performance penalty of having to request through a local distributed client process. 

One feature of the present invention, as recited in claim 6, and as similarly 
recited in claims 15 and 16, includes where the token revoke request includes 
information identifying the first client that requested the token for the file, and 
information indicating a level of the token requested by the first client, the level being 
either read or write. (See, e.g., page 15, lines 8-17 of the present specification). 
Loucks does not disclose this feature. 
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On page 6 (last line) to page 7, line 3 of the Office Action, the Examiner 
concedes that Loucks does not disclose the information contained in the token 
revoke request in the claims as previously presented. Applicants further submit that 
Loucks is silent regarding the contents of the token revoke request. Accordingly, it 
follows that Loucks does not teach or suggest the contents of the token revoke 
request as recited in the claims, as currently amended. Namely, Loucks fails to 
teach or suggest where the token revoke request includes information identifying the 
first client that requested the token for the file, and information indicating a level of 
the token requested by the first client, the level being either read or write. 

Therefore, Loucks fails to teach or suggest " wherein said token revoke 
request includes information identifying the first client that requested the token for 
said file, and information indicating a level of the token requested by said first client, 
said level being either read or write " as recited in claim 6, and as similarly recited in 
claims 15 and 16. 

The above noted deficiencies of Loucks are not supplied by any of the other 
references of record, namely Johnson, whether taken individually or in combination 
with each other. Therefore, combining the teachings of Loucks and Johnson in the 
manner suggested by the Examiner still fails to teach or suggest the features of the 
present invention as now more clearly recited in the claims. 

Johnson teaches a system and method for controlling client machine access 
to a portion of a file with a variable length. However, there is no teaching or 
suggestion in Johnson of the file send and receive method and program as recited in 
claims 6, 15 and 16 of the present invention. 
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Johnson discloses a system and method in which client access to data at a 
server is synchronized to keep the data consistent by ensuring that each portion of 
the data accessible for modification at a node is not accessible for reading or 
modification by any other node, while allowing portions of the data accessible only 
for reading to be accessible by any number of nodes. If a conflicting request arises 
from a different client the server must revoke data that has been previously 
distributed to a client. For a revoke_bytes request, all outstanding get_bytes are 
marked so that the bytes that are being requested to be revoked will be discarded 
when they do arrive at the client. To insure that read and write system calls on a file 
are performed in a serializable fashion throughout a distributed environment, each 
machine at which a read is being performed must acquire a read token and each 
machine at which a write is being performed must acquire a read/write token from 
the server for the file. When any machine has a read/write token, no machine is 
allowed to have a read token, although any number of machines may have a read 
token at the same time. The server coordinates the distribution of these tokens by 
revoking all read tokens whenever a write token is requested and revoking the write 
token whenever any read token is requested. 

One feature of the present invention, as recited in claim 6, and as similarly 
recited in claims 15 and 16, includes where the token revoke request includes 
information identifying the first client that requested the token for the file, and 
information indicating a level of the token requested by the first client, the level being 
either read or write. (See, e.g., page 15, lines 8-17 of the present specification). 
Johnson does not disclose this feature. 
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On page 7 (paragraph 29) of the Office Action, the Examiner relies upon 
Johnson for teaching where the contents of the token revoke request contains 
information, as recited in the previously presented claims. To support this assertion, 
the Examiner cites column 1 1 , lines 35-48 to column 13, lines 28-45. However, the 
cited text in column 1 1 , lines 45-48 is merely directed to acquiring a read or write 
token, and the cited text at column 13, lines 28-45 is merely directed to the operation 
of a revoke token process that occurs in response to a revoke token request and 
where the token is examined to determine if it is currently locked. Contrary to the 
Examiner's assertions, Johnson is silent regarding the contents of the token revoke 
request. Accordingly, it follows that Johnson does not teach or suggest the contents 
of the token revoke request as recited in the claims, as currently amended. Namely, 
Johnson fails to teach or suggest where the token revoke request includes 
information identifying the first client that requested the token for the file, and 
information indicating a level of the token requested by the first client, the level being 
either read or write. 

Therefore, Johnson fails to teach or suggest "wherein said token revoke 
request includes information identifying the first client that requested the token for 
said file, and information indicating a level of the token requested bv said first client, 
said level being either read or write " as recited in claim 6, and as similarly recited in 
claims 15 and 16. 

Both Loucks and Johnson suffer from the same deficiencies, relative to the 
features of the present invention, as recited in the claims. Therefore, combining the 
teachings of Loucks and Johnson in the manner suggested by the Examiner does 
not render obvious the features of the present invention as now more clearly recited 
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in the claims. Accordingly, reconsideration and withdrawal of the 35 U.S.C. §1 03(a) 
rejection of claims 6, 8, 15 and 16 as being unpatentable over Loucks in view of 
Johnson are respectfully requested. 

The remaining references of record have been studied. Applicants submit 
that they do not supply any of the deficiencies noted above with respect to the 
references used in the rejection of claims 6, 8, 1 5 and 1 6. 

Claims 1, 3, 11 and 12 stand rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Loucks in view of Johnson, and further in view of U.S. Patent 
Application Publication No. 2003/01 101 17 to Saidenberg et al. ("Saidenberg"). This 
rejection is traversed for the following reasons. Applicants submit that the features 
of the present invention, as now more clearly recited in claims 1 , 3, 1 1 and 12, are 
not taught or suggested by Loucks, Johnson or Saidenberg, whether taken 
individually or in combination with each other in the manner suggested by the 
Examiner. Therefore, Applicants respectfully request the Examiner to reconsider 
and withdraw this rejection. 

Amendments were made to the claims to more clearly describe features of the 
present invention. Specifically, amendments were made to the claims to more 
clearly recite that the present invention is directed to a distributed file system and a 
client device as recited, for example, in independent claims 1 and 1 1 . 

The present invention, as recited in claim 1 , and as similarly recited in claim 
1 1 , provides a distributed file system. The system includes a storage device for 
holding files, and multiple clients for carrying out file operations on the storage 
device. The system also includes a server using tokens to control rights to file 
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reading and writing operations by the clients, and a network connecting the clients, 
the storage device and the server. According to the present invention, the server 
contains a token revoke request means for sending a token revoke request for 
demanding a return of a token granting rights to write on the file, to a first client that 
holds the token. Also according to the present invention, the token revoke request 
means sends the token revoke request, which includes information identifying a 
second client that requested the file, and information indicating a level of the token 
requested by the second client, the level being either read or write. Furthermore, 
according to the present invention, the first client includes a memory section for 
holding file data loaded from the storage device and a data output means for sending 
the file held in the memory section and relating to the token, to the server for the 
second client that requested the token when the token revoke request is received. 
The prior art does not teach or suggest all of these features. 

The above described features of the present invention, as now more clearly 
recited in the claims, are not taught or suggested by any of the references of record. 
Specifically, the features are not taught or suggested by either of Loucks, Johnson or 
Saidenberg, whether taken individually or in combination with each other. 

As previously discussed, Loucks teaches a system and method for multi-level 
token management for distributed file systems. However, there is no teaching or 
suggestion in Loucks of the distributed file system or the client device as recited in 
claims 1 and 1 1 of the present invention. 

One feature of the present invention, as recited in claim 1 , and as similarly 
recited in claim 1 1 , includes where the token revoke request means sends the token 
revoke request, which includes information identifying a second client that requested 
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the file, and information indicating a level of the token requested by the second 
client, the level being either read or write. (See, e.g., page 15, lines 8-17 of the 
present specification). Loucks does not disclose this feature. 

On page 13 (paragraph 45) of the Office Action, the Examiner concedes that 
Loucks does not disclose the information contained in the token revoke request in 
the claims as previously presented. Applicants further submit that Loucks is silent 
regarding the contents of the token revoke request. Accordingly, it follows that 
Loucks does not teach or suggest the contents of the token revoke request as 
recited in the claims, as currently amended. Namely, Loucks fails to teach or 
suggest where the token revoke request includes information identifying the first 
client that requested the token for the file, and information indicating a level of the 
token requested by the first client, the level being either read or write. 

Therefore, Loucks fails to teach or suggest " wherein said token revoke 
request means sends said token revoke request, which includes information 
identifying a second client that requested said file, and information indicating a level 
of said token requested bv said second client, said level being either read or write " 
as recited in claim 1 , and as similarly recited in claim 1 1 . 

The above noted deficiencies of Loucks are not supplied by any of the other 
references of record, namely Johnson, whether taken individually or in combination 
with each other. Therefore, combining the teachings of Loucks and Johnson in the 
manner suggested by the Examiner still fails to teach or suggest the features of the 
present invention as now more clearly recited in the claims. 

As previously discussed, Johnson teaches a system and method for 
controlling client machine access to a portion of a file with a variable length. 
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However, there is no teaching or suggestion in Johnson of the distributed file system 
or the client device as recited in claims 1 and 1 1 of the present invention. 

One feature of the present invention, as recited in claim 1 , and as similarly 
recited in claim 1 1 , includes where the token revoke request means sends the token 
revoke request, which includes information identifying a second client that requested 
the file, and information indicating a level of the token requested by the second 
client, the level being either read or write. (See, e.g., page 15, lines 8-17 of the 
present specification). Johnson does not disclose this feature. 

On page 13 (paragraph 46) of the Office Action, the Examiner relies upon 
Johnson for teaching where the contents of the token revoke request contains 
information, as recited in the previously presented claims. To support this assertion, 
the Examiner cites column 1 1 , lines 35-48 to column 13, lines 28-45. However, the 
cited text in column 1 1 , lines 45-48 is merely directed to acquiring a read or write 
token, and the cited text at column 13, lines 28-45 is merely directed to the operation 
of a revoke token process that occurs in response to a revoke token request and 
where the token is examined to determine if it is currently locked. Contrary to the 
Examiner's assertions, Johnson is silent regarding the contents of the token revoke 
request. Accordingly, it follows that Johnson does not teach or suggest the contents 
of the token revoke request as recited in the claims, as currently amended. Namely, 
Johnson fails to teach or suggest where the token revoke request includes 
information identifying the first client that requested the token for the file, and 
information indicating a level of the token requested by the first client, the level being 
either read or write. 
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Therefore, Johnson fails to teach or suggest "wherein said token revoke 
request means sends said token revoke request, which includes information 
identifying a second client that requested said file, and information indicating a level 
of said token requested by said second client, said level being either read or write " 
as recited in claim 1 , and as similarly recited in claim 1 1 . 

The above noted deficiencies of Loucks in view of Johnson are not supplied 
by any of the other references of record, namely Saidenberg, whether taken 
individually or in combination with each other. Therefore, combining the teachings of 
Loucks, Johnson and Saidenberg in the manner suggested by the Examiner still fails 
to teach or suggest the features of the present invention as now more clearly recited 
in the claims. 

Saidenberg teaches a system and method for providing integrated 
applications availability in a networked computer system. However, there is no 
teaching or suggestion in Saidenberg of the distributed file system or the client 
device as recited in claims 1 and 1 1 of the present invention. 

Saidenberg discloses systems and methods for providing integrated 
applications availability in a networked computer system. The system includes a 
network including at least one client computer and at least one host server computer. 
A host server computer engaged in a session with a client computer causes display 
of a window on a display device of a client computer, the window including a number 
of display areas, each of the display areas displaying initial content provided through 
a different application. For example, upon selection of a portion of one or the 
displays, a second window is displayed that includes additional content. Session 
information is stored in a database separately from the client computer and the host 
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server computer engaged in the session. Session information obtained from the 
database is used in causing at least one of the display of the second window and 
display of a window comprising further content. 

One feature of the present invention, as recited in claim 1 , and as similarly 
recited in claim 1 1 , includes where the token revoke request means sends the token 
revoke request, which includes information identifying a second client that requested 
the file, and information indicating a level of the token requested by the second 
client, the level being either read or write. (See, e.g., page 15, lines 8-17 of the 
present specification). Saidenberg does not disclose this feature, and the 
Examiner does not rely upon Saidenberg for disclosing the contents of the token 
revoke request means. 

Therefore, Saidenberg fails to teach or suggest " wherein said token revoke 
request means sends said token revoke request, which includes information 
identifying a second client that requested said file, and information indicating a level 
of said token requested by said second client, said level being either read or write" 
as recited in claim 1 , and as similarly recited in claim 1 1 . 

Each of Loucks, Johnson and Saidenberg suffer from the same deficiencies, 
relative to the features of the present invention, as recited in the claims. Therefore, 
combining the teachings of Loucks, Johnson and Saidenberg in the manner 
suggested by the Examiner does not render obvious the features of the present 
invention as now more clearly recited in the claims. Accordingly, reconsideration 
and withdrawal of the 35 U.S.C. §103(a) rejection of claims 1,3, 11 and 12 as being 
unpatentable over Loucks in view of Johnson, and further in view of Saidenberg are 
respectfully requested. 
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The remaining references of record have been studied. Applicants submit 
that they do not supply any of the deficiencies noted above with respect to the 
references used in the rejection of claims 1,3,11 and 1 2. 

In view of the foregoing amendments and remarks, Applicants submit that 
claims 1, 3-6 and 8-16 are in condition for allowance. Accordingly, early allowance 
of claims 1, 3-6 and 8-16 is respectfully requested. 

To the extent necessary, Applicants petition for an extension of time under 37 
CFR 1.136. Please charge any shortage in fees due in connection with the filing of 
this paper, including extension of time fees, or credit any overpayment of fees, to the 
deposit account of Mattingly, Stanger & Malur, P.C., Deposit Account No. 50-1417 
(referencing Attorney Docket No. 1213.43347X00). 



Respectfully submitted, 



MATTINGLY, STANGER, MALUR & BRUNDIDGE, P.C. 




Donna K. Mason 
Registration No. 45,962 



DKM/cmd 
(703) 684-1120 
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